TeamTNT vuelve al trabajo, después de que Docker apunte a los servidores de AWS
Trendmicro
expone a la organización criminal TeamTNT por segunda vez.
El informe publicado por la compañía de seguridad confirma que ha encontrado una segunda versión de la botnet, más potente y refinada. Si una versión anterior del malware solo afectaba a Docker, ahora también puede afectar a los servidores de AWS.
Los desarrolladores de TeamTNT ya no solo están interesados en la minería, pero ahora se están desarrollando scripts maliciosos para robar datos como credenciales y contraseñas. Además, la nueva versión de la botnet es capaz de preparar el entorno para asegurarse de que tiene suficientes recursos para socavar la seguridad de otras plataformas, de hecho, se esconden en el sistema y también instalan puertas traseras en caso de que necesiten conectarse de forma remota a los servidores infectados.
¿Qué pasa? TeamTNT accede a los contenedores Docker expuestos, instala malware de minería cripot y roba credenciales de los servidores de AWS para pasar a otros sistemas de TI de una empresa para infectar aún más servidores e implementar mineros de criptomonedas. Este tipo de ataque es peligroso para las empresas que están expuestas en línea y también para aquellas que utilizan las API de administración de Docker. En este punto surge una pregunta, ¿es realmente posible sufrir un ataque de este tipo? ¿Cómo se puede dejar espacio y dar libre acceso a los contenedores?
La respuesta está relacionada con una de las siguientes alternativas:
- Errores en la aplicación u otras piezas de software contenidas en el contenedor;
- Las API de Docker están expuestas a todos;
- Repositorios Git no seguros o mal protegidos (credenciales públicas finitas, etc.);
- Cualquier base de datos utilizada por la aplicación expuesta en internet.
Para no caer en el error y evitar exponerse a riesgos de este tipo, hemos elaborado una lista de Buenas Prácticas a poner en marcha para proteger a los clientes de un posible ataque de malware:
- Uso de roles de IAM en lugar de utilizar claves de programación, como la clave de acceso y el acceso secreto, para llamadas autenticadas a servicios de AWS
- Organización de redes con subredes públicas/privadas para proteger los nodos «maestros» si se utiliza EKS o no se expone EC2 en caso de ECS en EC2
- Disponga de un único punto de acceso a la infraestructura (como CDN) que luego estará protegido con Web Application Firewall (WAF) para evitar ataques DDoS, XSS, SQL Injection (pila ISO/OSI de nivel 7 de protección) y protección de nivel 3-4.
- Usar siempre repositorios privados (Code Commit/git/ecr)
- No exponga las credenciales de la aplicación en repositorios, sino con otras soluciones, como buckets de S3 bloqueados por políticas estrictas, AWS System Manager.
Además, hay que recordar que todas las llamadas a los servicios de AWS requieren autenticación, incluso a través de API, y que AWS no expone nada en internet por defecto.
Aquí hay dos estudios de casos del mundo real en los que VMEngine pudo establecer todas las políticas de seguridad de la mejor manera posible, lo que afectó positivamente el rendimiento y hizo que la arquitectura de TI fuera segura y escalable:
